Smartcards and proximity cards provide numerous applications such as access control to systems and devices including data storage, and transaction management for electronic currency, e.g., eMoney. In today's security-sensitive world, smartcards offer a great advantage to providers of consumer devices and services. Smartcard support may be available in consumer and business electronic devices, such as Multi Function Peripherals (MFPs). A smartcard-based system typically includes a computer, a smartcard reader, and a smartcard. In standard system configurations, the smartcard reader is attached to the computer, e.g., a personal computer (PC), a workstation, or a mainframe system, and the smartcard-based computer system provides the necessary software components, executed as machine-readable instructions, in order to access the smartcard reader and, in turn, information of the smart card. A typical smartcard-based system software infrastructure within the computer system provides the communication protocol layer, i.e. the Input/Output (IO) drivers, in order for there to be communication with the reader device. Also, the computer system typically provides the communication software layer, i.e., the device drivers, in order to be in communication with the reader software. The computer system typically provides what is termed the card services layer in order to be in communication with the card. The computer system must provide the application layer that manages the application-specific data of the smartcard. Furthermore, the existence of numerous card formats and types only adds to the complexity of an already complex system. Given the complexities of smartcard-based systems, it is often times difficult, and sometimes impossible, to provide smartcard support within consumer devices or peripherals. Consumer devices may not have the necessary computing power and memory needed to implement the smartcard infrastructure.
A universal serial bus (USB) server allows USB data from one machine to be routed to another machine on the network. A USB-type reader may be attached to a remote machine, and the remote machine may function as a USB server to the attached USB reader. The remote machine typically provides special software that allows it to communicate over the network using a special port designated for its USB traffic. The application server also typically provides special software that listens on the port number designated for the USB traffic. This communication is bidirectional, and both machines implement special firmware to pack and unpack USB data over the network. While application servers may provide the capability to access remote smartcard readers on a different machine, USB-type readers are restricted, and this restriction effectively precludes the engagement of readers that utilize serial, a protocol according to the Personal Computer Memory Card International Association (PCMCIA), or other communication protocols. Additionally, USB over Ethernet may not provide the level of security needed for accessing the smartcard reader. For example, malicious applications may spoof the network to extract secure sensitive USB data. It should be noted that USB servers typically route all USB data. So, if the remote machine supports multiple USB devices, the USB data from all devices will be routed to the application server.
FIG. 1 depicts the state of the art in a simplified diagrammatic representation of the layers in a smartcard-based computer system 100. The layers that are depicted are: the card layer 110, the device layer 120, the IO device driver layer 130, the device driver, i.e., the interface device (IFD) layer 140, the card service provider 150, and the smartcard-aware application 160. The configuration of these layers is dictated by numerous industry standards and protocols, such as: ISO 7816; ISO 14443; ISO15693; HID™ re: radio frequency identification (RFID); iCLASS™ re: contactless communication; Mifare™ re: wireless transmission; Indala™ re: proximity; and Common Access Card (CAC) protocols.
The configuration of a smartcard-based system may be complex, and require considerable software infrastructure within the computer system. In some smartcard-based application systems, the smartcard itself may be considered as performing functions. Classes of smartcards such as CAC, iCLASS, and Mifare are equipped with built-in processors and memory chips that require complex firmware drivers in order to extract user credentials and data from the card. Additionally, there are several standards that pertain to smartcards. For example, ISO 7816 defines a standard for contact-based smartcards, ISO 14443 defines a standard for short-range contactless cards, and ISO 15693 defines a standard for longer-range contactless, i.e., noncontact smartcards. In addition, communication over computer networks is typically accomplished in accordance with protocols that meet standards including several superimposed software layers. These layers include IP, TCP, HTTP, and SOAP. SOAP was originally defined as Simple Object Access Protocol, and is a protocol specification for exchanging structured information in the implementation of web services in computer networks. SOAP relies on Extensible Markup Language (XML) as its message format and, for message negotiation and transmissions, SOAP typically relies on other Application Layer protocols, such as Remote Procedure Call (RPC) and HTTP.
The Personal Computer/Smart Card (PCSC) specifications define an industry standard infrastructure for supporting the numerous smartcard technologies within the computing environment. PCSC is predominantly used within the WINDOWS™ and LINUX™ operating systems, and supports the numerous industry standard protocols related to smartcard and proximity cards. Accordingly, PCSC has become a de facto standard for smartcard support. Many manufacturers and providers of smartcard and smartcard devices offer PCSC versions of their products and services.
FIG. 2 is a diagram depicting the state of the art as to PCSC architecture 200. Codes for smartcards are under the auspices of the International Code Council (ICC) and are integrated into the PCSC architecture. The top level is the ICC-aware applications level 210. The ICC service provider level 220 is subordinate to the ICC-aware applications level 210. The security pin entry for class 2/3 readers level 230 is subordinate to the ICC service provider level 220. IFD service provider level 240 is subordinate to both the ICC-aware applications level 210 and the ICC service provider level 220. The ICC resource manager level 250 is subordinate to all four of the preceding levels. The IFD handler level 260 is subordinate to the ICC resource manager level 250 and may comprise a plurality of individual IFD handlers. The IFD level 270 is subordinate to the IFD handler level 260, and is both superior to and functionally integral with the ICC cards/level 280.